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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 60 
countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel:H-4122 717 21 11 
Fax:H-41 22 717 24 81 

Founded in September 1993, the DVB Project is a market-led consortium of public and private sector 
organizations in the television industry. Its aim is to establish the framework for the introduction of 
MPEG-2 based digital television services. Now comprising over 200 organizations from more than 
25 countries around the world, DVB fosters market-led systems, which meet the real needs, and economic 
circumstances, of the consumer electronics and the broadcast industry. 

The specifications for the following Java packages are contained in archive ts_102757v010101p0.zip (in HTML and 
JAVA files) which accompanies the present document. 

it.dtt.ca 

it. dtt.ca. event 

it.dtt.ca. exception 

it.dtt.ca.history 

it.dtt.ca.ppv 

it.dtt.ca.request 

it.dtt.ca.response 

it.dtt.ca.util 
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Introduction 



Some years ago, the DAVIC organisation defined a conditional access API - which is included in MHP. This API can 
be implemented using both embedded conditional access and DVB common interface. In order to ensure the latter, the 
capabilities of this API were designed to fit those of the DVB common interface. A major part of this API is allowing 
MHP applications to receive so-called "high level" MMI messages and present them with a look and feel determined by 
the application provider. 

Those high level MMI messages were developed at a time when conditionally accessed TV was a relatively simple 
operation, essentially based on a subscription TV model with set-top boxes implementing a single conditional access 
system. Today, recent developments have shown that those assumptions are no longer true: 

1) CA systems are used for a variety of encrypted Free to View Channels. 

2) Commercial deployment of multi CA receivers (with as many as 3 resident systems) is becoming more 
common. 

3) New business model based on Subscription VOD, Pay per Use, Pay per Time, Pay per Event, etc. are 
becoming more and more important. 

4) Introduction of pre-paid CA smart cards. 

5) Introduction of wallet based payments (based on local transactions without return channel). 

6) Interaction with the end user is generally based on broadcast MHP applications that can be customized both 
from the look and feel and the behaviour point of view. It is no longer reasonable to expect that CA user 
interfaces can, or should, be limited to the implementation by the manufacturer. 

The present document is a formalisation of a specification developed by the DGTVi for MHP in Italy, under the name 
of MHP CA API 1.2 [i.5]. In the Italian market in fact the assumptions behind the original DAVIC API were incorrect 
and, more than this, complex Pay TV services based on horizontal interactive MHP-based set-top boxes were 
introduced. Most MHP boxes in the Italian market include at least two conditional access systems with both connected 
to an implementation of that specification. The present document is believed to be backwards compatible with the parts 
of that original work which are used in the market. Not all of the original specification is used in practice and the 
present document is not backwards compatible with some parts which are not used. 
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Scope 



The present document defines an API whose main goal is to to permit MHP or GEM applications to purchase protected 
content. Several other features can be supported in addition to this main goal including secure messaging and access to 
smart cards - including ones not related to a conditional access or content protection system. 

Although the package name includes "ca", the API is not specific to content protected by a content protection system, 
the API can also be used with content protected by a DRM system or other means. Although the package name includes 
"dtt", the API is neither specific to DTT nor to broadcast content, as it can also be used with IPTV delivered content . 
These naming conventions are kept to maintain backwards compatibility with current implementation in the market. 

The scope of the API includes the following features: 

• Obtaining lists of content available to be purchased. 

• Requesting the purchasing of a one or more items of content from a content protection system. 

• Support information about purchasing and smart card general management including, for example, giving 
access to purchase history, recharge history or information about the specific smart card. 

The API itself is not intended to be secure. All security requirements are intended to be addressed by the underlying 
content protection system. 

The present document is intentionally not a complete specification either for implementers or for application 
developers. It is intended to be read in conjunction with a document specific to a particular deployment of a particular 
content protection system. Such additional document would address issues such as the following; 

• How many of the API features are implemented in that particular deployment. 

• Which of the implemented API features are available to which applications - with or without authentication. 
Neither of these are addressed in the present document. 

It is important to emphasize that the API defined in the present document is optional and that: 

No conditional access or content protection system used in an MHP deployment is obligated to use this API or 
any part of it. 

Any MHP deployment that does choose to use this API, or any part of it, can extend it in any way. The 
specific extensions and the extension mechanism will be defined by an additional document specific to that 
deployment. Extensions should not override any functionality already defined in the API. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 



• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 
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For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] Java TV API 1.0, part of ISBN:l-892488-25-6. 

NOTE: Available from http://iava.sun.com/products/specformhp/ . 

[2] Java TV API 1 . 1 (JSR-927). 

NOTE: Available from http://www.icp. org/en/isr/detail?id=927 . 

[3] DA VIC 1 .4. 1 Specification Part 9. 

NOTE: Available from http://docbox.etsi.org/Reference/DAVIC . 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI ES 201 812: "Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) 

Specification 1.0.3". 

[i.2] ETSI TS 102 812: "Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) 

Specification 1.1.1". 

[i.3] ETSI TS 102 590: "Digital Video Broadcasting (DVB); Mulimedia Home Platform 1.2". 

[i.4] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 

in DVB systems". 

[4] CENELEC EN 50221: "Common Interface Specification for Conditional Access and other Digital 

Video Broadcasting Decoder Applications". 

[i.5] DGTVi "DTT CA API 1 .2" specification. 

NOTE: Available on request from info@dgtvi.it or from http://atlantis.tilab.com/proiects/ca api/ . 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

API: interface between an application and a particular feature, function or resource of the MHP 
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3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

API Application Programming Interface 

DA VIC Digital Audio Visual Council 

DVB-SI Digital Video Broadcasting - Service Information 

MMI Man-Machine Interface 



General 



4.1 APIs 

The present document requires the presence of the following packages - it.dtt.ca, it.dtt.ca.event, it.dtt.ca. exception, 
it.dtt.ca.history, it.dtt.ca.ppv, it.dtt.ca.request, it.dtt.ca.response, it.dtt.ca.util. The extent to which these are implemented 
in any particular deployment of a particular content protection system is defined by the additional document specific to 
that deployment. 

4.2 Platform dependencies 

The present document requires the presence of an implementation of either one of the following: 

• JavaTV 1.0 [1]. 

• JavaTV 1.1 [2]. 

The present document also requires the presence of the org.davic. resource. ResourceClient interface defined in 
DA VIC 1.4.1 part 9 [3] as found in MHP 1.0 [i.l], MHP 1.1 [i.2] or MHP 1.2 [i.3]. The extent to which the methods on 
this interface are called in any particular deployment of a particular content protection system is defined by the 
additional document specific to that deployment. 



4.3 Throwing RuntimeExceptions 



The present document intentionally does not define when RuntimeExceptions (such as SecurityException) are thrown. 
When methods throw these and the circumstances under which they are thrown is expected to form part of the 
additional document containing content protection system and deployment specific information, given the access to 
some APIs could be limited by the policies of a specific content protection system. 



4.4 Input and output parameters 



Where methods take an array as an input parameter, implementations should take a copy of the array. Where methods 
return an array, a copy should be returned and modifications to the array should be ignored by the implementation until 
or unless the array is passed back to the implementation as a parameter to a method call. 

NOTE: For new implementations, it is recommended that the should statements in the previous paragraph are 
considered to be shall statements. 
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5 System integration 

5.1 Parental and maturity rating 

The solution in the present document, when used in combination with the javax.tv. service. selection package, provides 
2 mechanisms for enforcing maturity rating and parental access control. 

• One provided by the implementation of the javax.tv. service. selection package (or a part of a generic media 
player called by that package). 

• A second one provided by the content protection system. 

Both mechanisms report failure to access content due to parental access control through events in the 
javax.tv. service. selection package. These include: 

• SelectionFailedEvent with reason code CA_REFUSAL where parental access control is enforced by the 
content protection system and failure results in presentation of content being stopped. 

• AlternateContentEvent where parental access control is enforced by the content protection system and failure 
results in alternative content being presented rather than that which was requested. 

• SelectionFailedEvent with reason code with reason code OTHER where parental access control is enforced by 
the implementation of the javax.tv.service. selection package. 

The present document intentionally does not define the following/ 

• Any requirement on content protection systems to provide parental access control at all. 

• The source of the maturity rating information about content used by content protection system based parental 
access control. 

• The order in which the two mechanisms are applied where both are implemented. 

In devices where both mechanisms are implemented, some content may use one mechanism and other content may use 
the other mechanism. For example, in a network with some scrambled services and some clear to air services, the 
content protection mechanism may enforce parental access control for scrambled services and the implementation of 
javax.tv. service. selection for the clear to air services. 

Applications may discover the rating information about content as follows/ 

• In the content purchase API using PPVEvent.getRating. 

• In MHP implementations, in the org.dvb.si API by obtaining the parental rating descriptor. 

• In the javax.tv. service. selection API using ProgramEvent.getRating. 

NOTE 1: Where DVB-SI [i.4] signalling is used, the mapping from the signalling to this API is defined by 

clause O.2.10 "javax.tv.service.RatingDimension" of MHP 1.0 [i.l], MHP 1.1 [i.2] or MHP 1.2 [i.3]. 

In devices where content protection based enforcement is used for all content, the implementation of the 
javax.tv.service. selection package is not required to duplicate this enforcement. 

For instances of javax.tv.service. guide. ContentRatingAdvisory which are returned from methods defined in the present 
document, the references to program events shall be interpreted as references to PPV and PPT events as defined in the 
present document. The reference to the system rating ceiling shall be interpreted as a reference to a rating ceiling 
imposed by the content protection system. 

NOTE 2: The rating region used by implementations of the present document need not be the same as the rating 
region used by implementations of the JavaTV [1] or [2] implementation in the same device". 
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Annex A (informative): 

Use-cases and mapping to the APIs 

A.1 Example service configuration 

Assume a broadcast channel with 2 films, "Ghost" from 19.00 to 21.00 and "Matrix" from 21.00 to 23.00. For "Matrix", 
there is a purchase window from 19.45 to 21.20. This is shown in figure A.l. 



19.00 



Movie "Ghost" 


Movie "Matrix" 


19.45 


21.00 21.20 


23. 











Purchase v^indow period for the movie "Matrix" 
Figure A.l : Service configuration 



A.2 Pull mode 
A.2.1 User experience 

In this example, the user experience would be as follows: 

• user tunes at 20.00; 

• retrieves information on current and next event; 

• user purchases "Matrix" in advance. 
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A.2.2 Mapping to application behaviour and API calls 

Table 1 shows a mapping from this user experience to a sequence of actions taken by the user, the system and an 
apphcation. 

Table 1 : Sequence of actions taken by the user, the systm and an application 



User action 


System action 


Application action 




Launch application 








Opens a session with content purchasing API for 

provider X and service provider Y 

Retrieve information about currently running 

event and next one 

Get the name of the two events and show them 

to the user ("Ghost" and "Matrix") 

Retrieve start time of "Ghost" and tell it's started 

since 1 hour 

Retrieve start time of "Matrix" and tell it's starting 

in 1 hour 


"MATRIX" item is selected 










Retrieve description and extended description of 
the movie and show them on screen 
Retrieve the price and show it to the user 
Check the purchase window start time and, 
given it's started since 15 minutes, show the 
button "Purchase it!" on screen 


"Purchase it!" is selected 










Xlet performs request to purchase "Matrix" and 

waits for an event (as a listener) 

A BuyResponseEvent notifies purchase has 

ended successfully (credit decremented and 

content right stored) 

A message tells the user he has acquired right to 

watch Matrix, starting at 21 .00 



A.3 Push mode 
A.3.1 User experience 

In this example, the user experience would be as follows/ 

• user tunes at 2 1 .02. 

• information on current event is pushed to the user. 

• user purchases "Matrix" just started. 
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A.3.2 Mapping to application behaviour and API calls 

Table 2 shows a mapping from this user experience to a sequence of actions taken by the user, the system and an 
apphcation. 

Table 2: Sequence of actions taken by the user, the systm and an application 



User action 



click "Purchase it!" 



System action 

Launcli application on tuned service 



Application action 



Opens a session with content purchasing API 

for provider X and service provider Y 

content purchasing API notifies basic 

information (ID, price) about currently running 

event. 

Get the name of the event from ID (via EIT or 

other means). 

Check the purchase window start time and, 

given it's started since 2 minutes, show the 

button "Purchase it!" banner with all infos to 

the user (Buy "IVIatrix" started at 21 .00 for €5) 



Xlet performs request to purchase "Matrix" 

and waits for an event (as a listener). 

A BuyResponseEvent notifies purchase has 

ended successfully (credit decremented and 

content right stored). 

A message tells the user he has acquired 

right to watch IVIatrix, started at 21 .00. 
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